home *** CD-ROM | disk | FTP | other *** search
Text File | 2002-10-03 | 72.0 KB | 1,123 lines
xxxxffffssss____ddddbbbb((((1111MMMM)))) xxxxffffssss____ddddbbbb((((1111MMMM)))) NNNNAAAAMMMMEEEE xfs_db, xfs_db64 - debug an XFS filesystem SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS xxxxffffssss____ddddbbbb [ ----cccc cmd ] ... [ ----pppp prog ] [ ----rrrr ] [ ----xxxx ] xfs_special xxxxffffssss____ddddbbbb ----ffff [ ----cccc cmd ] ... [ ----pppp prog ] [ ----ffff ] [ ----rrrr ] [ ----xxxx ] file xxxxffffssss____ddddbbbb66664444 [ ----cccc cmd ] ... [ ----pppp prog ] [ ----ffff ] [ ----rrrr ] [ ----xxxx ] xfs_special xxxxffffssss____ddddbbbb66664444 ----ffff [ ----cccc cmd ] ... [ ----pppp prog ] [ ----rrrr ] [ ----xxxx ] file DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN _x_f_s__d_b is used to examine an XFS filesystem. Under rare circumstances it can also be used to modify an XFS filesystem, but that task is normally left to _x_f_s__r_e_p_a_i_r(1M) or to scripts such as _x_f_s__c_h_v_e_r that run _x_f_s__d_b. _x_f_s__d_b_6_4 is a 64-bit version of _x_f_s__d_b which is not as susceptible to running out of memory. It is available only on 64-bit capable systems. The options to _x_f_s__d_b are: ----cccc _c_m_d _x_f_s__d_b commands may be run interactively (the default) or as arguments on the command line. Multiple ----cccc arguments may be given. The commands are run in the sequence given, then the program exits. This is the mechanism used to implement _x_f_s__c_h_e_c_k(1M). ----ffff Specifies that the filesystem image to be processed is stored in a regular file (see the _m_k_f_s__x_f_s ----dddd _f_i_l_e option). This might happen if an image copy of a filesystem has been made into an ordinary file with _x_f_s__c_o_p_y(1M). ----pppp _p_r_o_g Set the program name for prompts and some error messages, the default value is _x_f_s__d_b or _x_f_s__d_b_6_4. ----rrrr Open _f_i_l_e or _x_f_s__s_p_e_c_i_a_l read-only. This option is required if _x_f_s__s_p_e_c_i_a_l is a mounted filesystem. It is only necessary to omit this flag if a command that changes data (wwwwrrrriiiitttteeee, bbbblllloooocccckkkkttttrrrraaaasssshhhh) is to be used. ----xxxx Specifies expert mode. This enables the wwwwrrrriiiitttteeee command. CCCCOOOONNNNCCCCEEEEPPPPTTTTSSSS _x_f_s__d_b commands can be broken up into two classes. Most commands are for the navigation and display of data structures in the filesystem. Other commands are for scanning the filesystem in some way. Commands which are used to navigate the filesystem structure take arguments which reflect the names of filesystem structure fields. There can be multiple field names separated by dots when the underlying structures are nested, as in C. The field names can be indexed (as an PPPPaaaaggggeeee 1111 xxxxffffssss____ddddbbbb((((1111MMMM)))) xxxxffffssss____ddddbbbb((((1111MMMM)))) array index) if the underlying field is an array. The array indices can be specified as a range, two numbers separated by a dash. _x_f_s__d_b maintains a current address in the filesystem. The granularity of the address is a filesystem structure. This can be a filesystem block, an inode or quota (smaller than a filesystem block), or a directory block (could be larger than a filesystem block). There are a variety of commands to set the current address. Associated with the current address is the current data type, which is the structural type of this data. Commands which follow the structure of the filesystem always set the type as well as the address. Commands which examine pieces of an individual file (inode) need the current inode to be set, this is done with the iiiinnnnooooddddeeee command. The current address/type information is actually maintained in a stack that can be explicitly manipulated with the ppppuuuusssshhhh, ppppoooopppp, and ssssttttaaaacccckkkk commands. This allows for easy examination of a nested filesystem structure. Also, the last several locations visited are stored in a ring buffer which can be manipulated with the ffffoooorrrrwwwwaaaarrrrdddd, bbbbaaaacccckkkk,,,, aaaannnndddd rrrriiiinnnngggg commands. XFS filesystems are divided into a small number of allocation groups. _x_f_s__d_b maintains a notion of the current allocation group which is manipulated by some commands. The initial allocation group is 0. CCCCOOOOMMMMMMMMAAAANNNNDDDDSSSS Many commands have extensive online help. Use the hhhheeeellllpppp command for more details on any command. aaaa See the aaaaddddddddrrrr command. aaaabbbblllloooocccckkkk _f_i_l_o_f_f Set current address to the offset _f_i_l_o_f_f (a filesystem block number) in the attribute area of the current inode. aaaaddddddddrrrr [ _f_i_e_l_d-_e_x_p_r_e_s_s_i_o_n ] Set current address to the value of the _f_i_e_l_d-_e_x_p_r_e_s_s_i_o_n. This is used to ``follow'' a reference in one structure to the object being referred to. If no argument is given the current address is printed. aaaaggggffff [ _a_g_n_o ] Set current address to the AGF block for allocation group _a_g_n_o. If no argument is given use the current allocation group. aaaaggggffffllll [ _a_g_n_o ] Set current address to the AGFL block for allocation group _a_g_n_o. If no argument is given use the current allocation group. PPPPaaaaggggeeee 2222 xxxxffffssss____ddddbbbb((((1111MMMM)))) xxxxffffssss____ddddbbbb((((1111MMMM)))) aaaaggggiiii [ _a_g_n_o ] Set current address to the AGI block for allocation group _a_g_n_o. If no argument is given use the current allocation group. bbbb See the bbbbaaaacccckkkk command. bbbbaaaacccckkkk Move to the previous location in the position ring. bbbblllloooocccckkkkffffrrrreeeeeeee Free block usage information collected by the last execution of the bbbblllloooocccckkkkggggeeeetttt command. This must be done before another bbbblllloooocccckkkkggggeeeetttt command can be given, presumably with different arguments than the previous one. bbbblllloooocccckkkkggggeeeetttt [ ----nnnnppppssssvvvv ] [ ----bbbb _b_n_o ] ... [ ----iiii _i_n_o ] ... Get block usage and check filesystem consistency. The information is saved for use by a subsequent bbbblllloooocccckkkkuuuusssseeee, nnnncccchhhheeeecccckkkk, or bbbblllloooocccckkkkttttrrrraaaasssshhhh command. See _x_f_s__c_h_e_c_k(1M) for more information. The ----bbbb option is used to specify filesystem block numbers about which verbose information should be printed. The ----iiii option is used to specify inode numbers about which verbose information should be printed. The ----nnnn option is used to save pathnames for inodes visited, this is used to support the _x_f_s__n_c_h_e_c_k(1M) command. It also means that pathnames will be printed for inodes that have problems. This option uses a lot of memory so is not enabled by default. The ----pppp option causes error messages to be prefixed with the filesystem name being processed. This is useful if several copies of _x_f_s__d_b are run in parallel. The ----ssss option restricts output to severe errors only. This is useful if the output is too long otherwise. The ----vvvv option enables verbose output. Messages will be printed for every block and inode processed. bbbblllloooocccckkkkttttrrrraaaasssshhhh [ ----nnnn _c ] [ ----xxxx _a ] [ ----yyyy _b ] [ ----ssss _s ] [ ----0000111122223333 ] [ ----tttt _t ] ... Trash randomly selected filesystem metadata blocks. Trashing occurs to randomly selected bits in the chosen blocks. This command is available only in debugging versions of _x_f_s__d_b. It is useful for testing _x_f_s__r_e_p_a_i_r(1M) and _x_f_s__c_h_e_c_k(1M). The ----0000, ----1111, ----2222, and ----3333 options (mutually exclusive) set the operating mode for bbbblllloooocccckkkkttttrrrraaaasssshhhh. In ----0000 mode, changed bits are cleared. In ----1111 mode, changed bits are set. In ----2222 mode, changed bits are inverted. In ----3333 mode, changed bits are randomized. The ----nnnn option supplies the count of block-trashings to perform (default 1). The ----ssss option supplies a seed to the random processing. The ----tttt option gives a type of blocks to be selected for trashing. Multiple ----tttt options may be given. If no ----tttt options are given then all metadata types can be trashed. The ----xxxx option sets the minimum size of bit range to be trashed. The default value is 1. PPPPaaaaggggeeee 3333 xxxxffffssss____ddddbbbb((((1111MMMM)))) xxxxffffssss____ddddbbbb((((1111MMMM)))) The ----yyyy option sets the maximum size of bit range to be trashed. The default value is 1024. bbbblllloooocccckkkkuuuusssseeee [ ----nnnn ] [ ----cccc _b_l_o_c_k_c_o_u_n_t ] Print usage for current filesystem block(s). For each block, the type and (if any) inode are printed. The ----cccc option specifies a count of blocks to process. The default value is 1 (the current block only). The ----nnnn option specifies that file names should be printed. The prior bbbblllloooocccckkkkggggeeeetttt command must have also specified the ----nnnn option. bbbbmmmmaaaapppp [ ----aaaa ] [ ----dddd ] [ _b_l_o_c_k [ _l_e_n ] ] Show the block map for the current inode. The map display can be restricted to an area of the file with the _b_l_o_c_k and _l_e_n arguments. If _b_l_o_c_k is given and _l_e_n is omitted then 1 is assumed for len. The ----aaaa and ----dddd options are used to select the attribute or data area of the inode, if neither option is given then both areas are shown. cccchhhheeeecccckkkk See the bbbblllloooocccckkkkggggeeeetttt command. ccccoooonnnnvvvveeeerrrrtttt _t_y_p_e _n_u_m_b_e_r [ _t_y_p_e _n_u_m_b_e_r ] ... _t_y_p_e Convert from one address form to another. The known _t_y_p_es, with alternate names, are: aaaaggggbbbblllloooocccckkkk or aaaaggggbbbbnnnnoooo (filesystem block within an allocation group), aaaaggggiiiinnnnoooo or aaaaggggiiiinnnnooooddddeeee (inode number within an allocation group), aaaaggggnnnnuuuummmmbbbbeeeerrrr or aaaaggggnnnnoooo (allocation group number), bbbbbbbbooooffffffff or ddddaaaaddddddddrrrrooooffffffff (byte offset in a ddddaaaaddddddddrrrr), bbbbllllkkkkooooffffffff or ffffssssbbbbooooffffffff or aaaaggggbbbbooooffffffff (byte offset in a aaaaggggbbbblllloooocccckkkk or ffffssssbbbblllloooocccckkkk), bbbbyyyytttteeee or ffffssssbbbbyyyytttteeee (byte address in filesystem), ddddaaaaddddddddrrrr or bbbbbbbb (disk address, 512-byte blocks), ffffssssbbbblllloooocccckkkk or ffffssssbbbb or ffffssssbbbbnnnnoooo (filesystem block, see the ffffssssbbbblllloooocccckkkk command), iiiinnnnoooo or iiiinnnnooooddddeeee (inode number), iiiinnnnooooiiiiddddxxxx or ooooffffffffsssseeeetttt (index of inode in filesystem block), and iiiinnnnooooooooffffffff or iiiinnnnooooddddeeeeooooffffffff (byte offset in inode). Only conversions that ``make sense'' are allowed. The compound form (with more than three arguments) is useful for conversions such as ccccoooonnnnvvvveeeerrrrtttt aaaaggggnnnnoooo _a_g aaaaggggbbbbnnnnoooo _a_g_b ffffssssbbbblllloooocccckkkk. ddddaaaaddddddddrrrr [ _d ] Set current address to the daddr (512 byte block) given by _d. If no value for _d is given the current address is printed, expressed as a daddr. The type is set to ddddaaaattttaaaa (uninterpreted). ddddbbbblllloooocccckkkk _f_i_l_o_f_f Set current address to the offset _f_i_l_o_f_f (a filesystem block number) in the data area of the current inode. ddddeeeebbbbuuuugggg [ _f_l_a_g_b_i_t_s ] Set debug option bits. These are used for debugging _x_f_s__d_b. If no value is given for _f_l_a_g_b_i_t_s, print the current debug option bits. These are for the use of the implementor. PPPPaaaaggggeeee 4444 xxxxffffssss____ddddbbbb((((1111MMMM)))) xxxxffffssss____ddddbbbb((((1111MMMM)))) ddddqqqquuuuooootttt [ _p_r_o_j_e_c_t_i_d__o_r__u_s_e_r_i_d ] Set current address to a project or user quota block. eeeecccchhhhoooo [ _a_r_g ] ... Echo the arguments to the output. ffff See the ffffoooorrrrwwwwaaaarrrrdddd command. ffffoooorrrrwwwwaaaarrrrdddd Move forward to the next entry in the position ring. ffffrrrraaaagggg [ ----aaaaddddffffllllqqqqRRRRrrrrvvvv ] Get file fragmentation data. This prints information about fragmentation of file data in the filesystem (as opposed to fragmentation of freespace, for which see the ffffrrrreeeeeeeesssspppp command). Every file in the filesystem is examined to see how far from ideal its extent mappings are. A summary is printed giving the totals. The ----vvvv option sets verbosity, every inode has information printed for it. The remaining options select which inodes and extents are examined. If no options are given then all are assumed set, otherwise just those given are enabled. The ----aaaa option enables processing of attribute data. The ----dddd option enables processing of directory data. The ----ffff option enables processing of regular file data. The ----llll option enables processing of symbolic link data. The ----qqqq option enables processing of quota file data. The ----RRRR option enables processing of realtime control file data. The ----rrrr option enables processing of realtime file data. ffffrrrreeeeeeeesssspppp [ ----bbbbccccddddssss ] [ ----aaaa _a ] ... [ ----eeee _i ] [ ----hhhh _h_1 ] ... [ ----mmmm _m ] Summarize free space for the filesystem. The free blocks are examined and totaled, and displayed in the form of a histogram, with a count of extents in each range of free extent sizes. The ----aaaa _a option adds _a to the list of allocation groups to be processed. If no ----aaaa options are given then all allocation groups are processed. The ----bbbb option specifies that the histogram buckets are binary- sized, with the starting sizes being the powers of 2. The ----cccc option specifies that ffffrrrreeeeeeeesssspppp will search the by-size (cnt) space Btree instead of the default by-block (bno) space Btree. The ----dddd option specifies that every free extent will be displayed. The ----eeee _i option specifies that the histogram buckets are equal-sized, with the size specified as _i. The ----hhhh _h_1 option specifies a starting block number for a histogram bucket as _h_1. Multiple ----hhhh options are given to specify the complete set of buckets. The ----mmmm _m option specifies that the histogram starting block numbers are powers of _m. This is the general case of ----bbbb. The ----ssss option specifies that a final summary of total free extents, free blocks, and the average free extent size is PPPPaaaaggggeeee 5555 xxxxffffssss____ddddbbbb((((1111MMMM)))) xxxxffffssss____ddddbbbb((((1111MMMM)))) printed. ffffssssbbbb See the ffffssssbbbblllloooocccckkkk command. ffffssssbbbblllloooocccckkkk [ _f_s_b ] Set current address to the fsblock value given by _f_s_b. If no value for _f_s_b is given the current address is printed, expressed as an fsb. The type is set to ddddaaaattttaaaa (uninterpreted). XFS filesystem block numbers are computed ((_a_g_n_o << _a_g_s_h_i_f_t) | _a_g_b_l_o_c_k) where _a_g_s_h_i_f_t depends on the size of an allocation group. Use the ccccoooonnnnvvvveeeerrrrtttt command to convert to and from this form. Block numbers given for file blocks (for instance from the bbbbmmmmaaaapppp command) are in this form. hhhhaaaasssshhhh _s_t_r_i_n_g Prints the hash value of _s_t_r_i_n_g using the hash function of the XFS directory and attribute implementation. hhhheeeellllpppp [ _c_o_m_m_a_n_d ] Print help for one or all commands. iiiinnnnooooddddeeee [ _i_n_o_d_e# ] Set the current inode number. If no _i_n_o_d_e# is given, print the current inode number. lllloooogggg [ ssssttttoooopppp | ssssttttaaaarrrrtttt _f_i_l_e_n_a_m_e ] Start logging output to _f_i_l_e_n_a_m_e, stop logging, or print the current logging status. nnnncccchhhheeeecccckkkk [ ----ssss ] [ ----iiii _i_n_o ] ... Print name-inode pairs. A bbbblllloooocccckkkkggggeeeetttt ----nnnn command must be run first to gather the information. The ----iiii option specifies an inode number to be printed. If no ----iiii options are given then all inodes are printed. The ----ssss option specifies that only setuid and setgid files are printed. pppp See the pppprrrriiiinnnntttt command. ppppoooopppp Pop location from the stack. pppprrrriiiinnnntttt [ _f_i_e_l_d-_e_x_p_r_e_s_s_i_o_n ] ... Print field values. If no argument is given, print all fields in the current structure. ppppuuuusssshhhh [ _c_o_m_m_a_n_d ] Push location to the stack. If _c_o_m_m_a_n_d is supplied, set the current location to the results of _c_o_m_m_a_n_d after pushing the old location. PPPPaaaaggggeeee 6666 xxxxffffssss____ddddbbbb((((1111MMMM)))) xxxxffffssss____ddddbbbb((((1111MMMM)))) qqqq See the qqqquuuuiiiitttt command. qqqquuuuiiiitttt Exit _x_f_s__d_b. rrrriiiinnnngggg [ _i_n_d_e_x ] Show position ring (if no _i_n_d_e_x argument is given), or move to a specific entry in the position ring given by _i_n_d_e_x. ssssbbbb [ _a_g_n_o ] Set current address to SB header in allocation group _a_g_n_o. If no _a_g_n_o is given use the current allocation group number. ssssoooouuuurrrrcccceeee _s_o_u_r_c_e-_f_i_l_e Process commands from _s_o_u_r_c_e-_f_i_l_e. ssssoooouuuurrrrcccceeee commands can be nested. ssssttttaaaacccckkkk View the location stack. ttttyyyyppppeeee [ _t_y_p_e ] Set the current data type to _t_y_p_e. If no argument is given, show the current data type. The possible data types are: aaaaggggffff, aaaaggggffffllll, aaaaggggiiii, aaaattttttttrrrr, bbbbmmmmaaaappppbbbbttttaaaa, bbbbmmmmaaaappppbbbbttttdddd, bbbbnnnnoooobbbbtttt, ccccnnnnttttbbbbtttt, ddddaaaattttaaaa, ddddiiiirrrr, ddddiiiirrrr2222, ddddqqqqbbbbllllkkkk, iiiinnnnoooobbbbtttt, iiiinnnnooooddddeeee, lllloooogggg, rrrrttttbbbbiiiittttmmmmaaaapppp, rrrrttttssssuuuummmmmmmmaaaarrrryyyy, ssssbbbb, and ssssyyyymmmmlllliiiinnnnkkkk. See the TYPES section below for more information on these data types. uuuuuuuuiiiidddd [ _n_e_w-_u_u_i_d | _g_e_n_e_r_a_t_e | _r_e_w_r_i_t_e ] Display or write the filesystem UUID. If no argument is given, show the current UUID. If a UUID is specified, write the new UUID to all superbolocks. If _g_e_n_e_r_a_t_e is specified, a new UUID is generated. If _r_e_w_r_i_t_e is specified, the UUID in the first superblock is copied to all other superblocks. wwwwrrrriiiitttteeee [ _f_i_e_l_d _o_r _v_a_l_u_e ] ... Write a value to disk. Specific fields can be set in structures (struct mode), or a block can be set to data values (data mode), or a block can be set to string values (string mode, for symlink blocks). The operation happens immediately: there is no buffering. Struct mode is in effect when the current type is structural, i.e. not data. For struct mode, the syntax is ``wwwwrrrriiiitttteeee _f_i_e_l_d _v_a_l_u_e''. Data mode is in effect when the current type is data. In this case the contents of the block can be shifted or rotated left or right, or filled with a sequence, a constant value, or a random value. In this mode wwwwrrrriiiitttteeee with no arguments gives more information on the allowed commands. TTTTYYYYPPPPEEEESSSS This section gives the fields in each structure type and their meanings. Note that some types of block cover multiple actual structures, for instance directory blocks. PPPPaaaaggggeeee 7777 xxxxffffssss____ddddbbbb((((1111MMMM)))) xxxxffffssss____ddddbbbb((((1111MMMM)))) aaaaggggffff The AGF block is the header for block allocation information; it is in the second 512-byte block of each allocation group. The following fields are defined: mmmmaaaaggggiiiiccccnnnnuuuummmm: AGF block magic number, 0x58414746 ('XAGF') vvvveeeerrrrssssiiiioooonnnnnnnnuuuummmm: version number, currently 1 sssseeeeqqqqnnnnoooo: sequence number starting from 0 lllleeeennnnggggtttthhhh: size in filesystem blocks of the allocation group. All allocation groups except the last one of the filesystem have the superblock's aaaaggggbbbblllloooocccckkkkssss value here bbbbnnnnoooorrrrooooooootttt: block number of the root of the Btree holding free space information sorted by block number ccccnnnnttttrrrrooooooootttt: block number of the root of the Btree holding free space information sorted by block count bbbbnnnnoooolllleeeevvvveeeellll: number of levels in the by-block-number Btree ccccnnnnttttlllleeeevvvveeeellll: number of levels in the by-block-count Btree ffffllllffffiiiirrrrsssstttt: index into the AGFL block of the first active entry ffffllllllllaaaasssstttt: index into the AGFL block of the last active entry ffffllllccccoooouuuunnnntttt: count of active entries in the AGFL block ffffrrrreeeeeeeebbbbllllkkkkssss: count of blocks represented in the freespace Btrees lllloooonnnnggggeeeesssstttt: longest free space represented in the freespace Btrees aaaaggggffffllll The AGFL block contains block numbers for use of the block allocator; it is in the fourth 512-byte block of each allocation group. Each entry in the active list is a block number within the allocation group that can be used for any purpose if space runs low. The AGF block fields ffffllllffffiiiirrrrsssstttt, ffffllllllllaaaasssstttt, and ffffllllccccoooouuuunnnntttt designate which entries are currently active. Entry space is allocated in a circular manner within the AGFL block. Fields defined: bbbbnnnnoooo: array of all block numbers. Even those which are not active are printed aaaaggggiiii The AGI block is the header for inode allocation information; it is in the third 512-byte block of each allocation group. Fields defined: mmmmaaaaggggiiiiccccnnnnuuuummmm: AGI block magic number, 0x58414749 ('XAGI') vvvveeeerrrrssssiiiioooonnnnnnnnuuuummmm: version number, currently 1 sssseeeeqqqqnnnnoooo: sequence number starting from 0 lllleeeennnnggggtttthhhh: size in filesystem blocks of the allocation group ccccoooouuuunnnntttt: count of inodes allocated rrrrooooooootttt: block number of the root of the Btree holding inode allocation information lllleeeevvvveeeellll: number of levels in the inode allocation Btree ffffrrrreeeeeeeeccccoooouuuunnnntttt: count of allocated inodes that are not in use nnnneeeewwwwiiiinnnnoooo: last inode number allocated ddddiiiirrrriiiinnnnoooo: unused uuuunnnnlllliiiinnnnkkkkeeeedddd: an array of inode numbers within the allocation group. The entries in the AGI block are the heads of lists which run through the inode nnnneeeexxxxtttt____uuuunnnnlllliiiinnnnkkkkeeeedddd field. These inodes are to be unlinked the next time the filesystem is mounted PPPPaaaaggggeeee 8888 xxxxffffssss____ddddbbbb((((1111MMMM)))) xxxxffffssss____ddddbbbb((((1111MMMM)))) aaaattttttttrrrr An attribute fork is organized as a Btree with the actual data embedded in the leaf blocks. The root of the Btree is found in block 0 of the fork. The index (sort order) of the Btree is the hash value of the attribute name. All the blocks contain a bbbbllllkkkkiiiinnnnffffoooo structure at the beginning, see type ddddiiiirrrr for a description. Nonleaf blocks are identical in format to those for version 1 and version 2 directories, see type ddddiiiirrrr for a description. Leaf blocks can refer to ``local'' or ``remote'' attribute values. Local values are stored directly in the leaf block. Remote values are stored in an independent block in the attribute fork (with no structure). Leaf blocks contain the following fields: hhhhddddrrrr: header containing a bbbbllllkkkkiiiinnnnffffoooo structure iiiinnnnffffoooo (magic number 0xfbee), a ccccoooouuuunnnntttt of active entries, uuuusssseeeeddddbbbbyyyytttteeeessss total bytes of names and values, the ffffiiiirrrrssssttttuuuusssseeeedddd byte in the name area, hhhhoooolllleeeessss set if the block needs compaction, and array ffffrrrreeeeeeeemmmmaaaapppp as for ddddiiiirrrr leaf blocks eeeennnnttttrrrriiiieeeessss: array of structures containing a hhhhaaaasssshhhhvvvvaaaallll, nnnnaaaammmmeeeeiiiiddddxxxx (index into the block of the name), and flags iiiinnnnccccoooommmmpppplllleeeetttteeee, rrrrooooooootttt, and llllooooccccaaaallll nnnnvvvvlllliiiisssstttt: array of structures describing the attribute names and values. Fields always present: vvvvaaaalllluuuueeeelllleeeennnn (length of value in bytes), nnnnaaaammmmeeeelllleeeennnn, and nnnnaaaammmmeeee. Fields present for local values: vvvvaaaalllluuuueeee (value string). Fields present for remote values: vvvvaaaalllluuuueeeebbbbllllkkkk (fork block number of containing the value). bbbbmmmmaaaappppbbbbtttt Files with many extents in their data or attribute fork will have the extents described by the contents of a Btree for that fork, instead of being stored directly in the inode. Each bmap Btree starts with a root block contained within the inode. The other levels of the Btree are stored in filesystem blocks. The blocks are linked to sibling left and right blocks at each level, as well as by pointers from parent to child blocks. Each block contains the following fields: mmmmaaaaggggiiiicccc: bmap Btree block magic number, 0x424d4150 ('BMAP') lllleeeevvvveeeellll: level of this block above the leaf level nnnnuuuummmmrrrreeeeccccssss: number of records or keys in the block lllleeeeffffttttssssiiiibbbb: left (logically lower) sibling block, 0 if none rrrriiiigggghhhhttttssssiiiibbbb: right (logically higher) sibling block, 0 if none rrrreeeeccccssss: [leaf blocks only] array of extent records. Each record contains ssssttttaaaarrrrttttooooffffffff, ssssttttaaaarrrrttttbbbblllloooocccckkkk, bbbblllloooocccckkkkccccoooouuuunnnntttt, and eeeexxxxtttteeeennnnttttffffllllaaaagggg (1 if the extent is unwritten) kkkkeeeeyyyyssss: [nonleaf blocks only] array of key records. These are the first key value of each block in the level below this one. Each record contains ssssttttaaaarrrrttttooooffffffff ppppttttrrrrssss: [nonleaf blocks only] array of child block pointers. Each pointer is a filesystem block number to the next level in the Btree bbbbnnnnoooobbbbtttt There is one set of filesystem blocks forming the by-block- number allocation Btree for each allocation group. The root block of this Btree is designated by the bbbbnnnnoooorrrrooooooootttt field in the PPPPaaaaggggeeee 9999 xxxxffffssss____ddddbbbb((((1111MMMM)))) xxxxffffssss____ddddbbbb((((1111MMMM)))) corresponding AGF block. The blocks are linked to sibling left and right blocks at each level, as well as by pointers from parent to child blocks. Each block has the following fields: mmmmaaaaggggiiiicccc: BNOBT block magic number, 0x41425442 ('ABTB') lllleeeevvvveeeellll: level number of this block, 0 is a leaf nnnnuuuummmmrrrreeeeccccssss: number of data entries in the block lllleeeeffffttttssssiiiibbbb: left (logically lower) sibling block, 0 if none rrrriiiigggghhhhttttssssiiiibbbb: right (logically higher) sibling block, 0 if none rrrreeeeccccssss: [leaf blocks only] array of freespace records. Each record contains ssssttttaaaarrrrttttbbbblllloooocccckkkk and bbbblllloooocccckkkkccccoooouuuunnnntttt kkkkeeeeyyyyssss: [nonleaf blocks only] array of key records. These are the first value of each block in the level below this one. Each record contains ssssttttaaaarrrrttttbbbblllloooocccckkkk and bbbblllloooocccckkkkccccoooouuuunnnntttt ppppttttrrrrssss: [nonleaf blocks only] array of child block pointers. Each pointer is a block number within the allocation group to the next level in the Btree ccccnnnnttttbbbbtttt There is one set of filesystem blocks forming the by-block- count allocation Btree for each allocation group. The root block of this Btree is designated by the corresponding AGF block. The blocks are linked to sibling left and right blocks at each level, as well as by pointers from parent to child blocks. Each block has the following fields: mmmmaaaaggggiiiicccc: CNTBT block magic number, 0x41425443 ('ABTC') lllleeeevvvveeeellll: level number of this block, 0 is a leaf nnnnuuuummmmrrrreeeeccccssss: number of data entries in the block lllleeeeffffttttssssiiiibbbb: left (logically lower) sibling block, 0 if none rrrriiiigggghhhhttttssssiiiibbbb: right (logically higher) sibling block, 0 if none rrrreeeeccccssss: [leaf blocks only] array of freespace records. Each record contains ssssttttaaaarrrrttttbbbblllloooocccckkkk and bbbblllloooocccckkkkccccoooouuuunnnntttt kkkkeeeeyyyyssss: [nonleaf blocks only] array of key records. These are the first value of each block in the level below this one. Each record contains bbbblllloooocccckkkkccccoooouuuunnnntttt and ssssttttaaaarrrrttttbbbblllloooocccckkkk ppppttttrrrrssss: [nonleaf blocks only] array of child block pointers. Each pointer is a block number within the allocation group to the next level in the Btree ddddaaaattttaaaa User file blocks, and other blocks whose type is unknown, have this type for display purposes in _x_f_s__d_b. The block data is displayed in hexadecimal format. ddddiiiirrrr A version 1 directory is organized as a Btree with the directory data embedded in the leaf blocks. The root of the Btree is found in block 0 of the file. The index (sort order) of the Btree is the hash value of the entry name. All the blocks contain a bbbbllllkkkkiiiinnnnffffoooo structure at the beginning with the following fields: ffffoooorrrrwwww: next sibling block bbbbaaaacccckkkk: previous sibling block mmmmaaaaggggiiiicccc: magic number for this block type The nonleaf (node) blocks have the following fields: PPPPaaaaggggeeee 11110000 xxxxffffssss____ddddbbbb((((1111MMMM)))) xxxxffffssss____ddddbbbb((((1111MMMM)))) hhhhddddrrrr: header containing a bbbbllllkkkkiiiinnnnffffoooo structure iiiinnnnffffoooo (magic number 0xfebe), the ccccoooouuuunnnntttt of active entries, and the lllleeeevvvveeeellll of this block above the leaves bbbbttttrrrreeeeeeee: array of entries containing hhhhaaaasssshhhhvvvvaaaallll and bbbbeeeeffffoooorrrreeee fields. The bbbbeeeeffffoooorrrreeee value is a block number within the directory file to the child block, the hhhhaaaasssshhhhvvvvaaaallll is the last hash value in that block The leaf blocks have the following fields: hhhhddddrrrr: header containing a bbbbllllkkkkiiiinnnnffffoooo structure iiiinnnnffffoooo (magic number 0xfeeb), the ccccoooouuuunnnntttt of active entries, nnnnaaaammmmeeeebbbbyyyytttteeeessss (total name string bytes), hhhhoooolllleeeessss flag (block needs compaction), and ffffrrrreeeeeeeemmmmaaaapppp (array of bbbbaaaasssseeee, ssssiiiizzzzeeee entries for free regions) eeeennnnttttrrrriiiieeeessss: array of structures containing hhhhaaaasssshhhhvvvvaaaallll, nnnnaaaammmmeeeeiiiiddddxxxx (byte index into the block of the name string), and nnnnaaaammmmeeeelllleeeennnn nnnnaaaammmmeeeelllliiiisssstttt: array of structures containing iiiinnnnuuuummmmbbbbeeeerrrr and nnnnaaaammmmeeee ddddiiiirrrr2222 A version 2 directory has four kinds of blocks. Data blocks start at offset 0 in the file. There are two kinds of data blocks: single-block directories have the leaf information embedded at the end of the block, data blocks in multi-block directories do not. Node and leaf blocks start at offset 32GB (with either a single leaf block or the root node block). Freespace blocks start at offset 64GB. The node and leaf blocks form a Btree, with references to the data in the data blocks. The freespace blocks form an index of longest free spaces within the data blocks. A single-block directory block contains the following fields: bbbbhhhhddddrrrr: header containing mmmmaaaaggggiiiicccc number 0x58443242 ('XD2B') and an array bbbbeeeessssttttffffrrrreeeeeeee of the longest 3 free spaces in the block (ooooffffffffsssseeeetttt, lllleeeennnnggggtttthhhh) bbbbuuuu: array of union structures. Each element is either an entry or a freespace. For entries, there are the following fields: iiiinnnnuuuummmmbbbbeeeerrrr, nnnnaaaammmmeeeelllleeeennnn, nnnnaaaammmmeeee, and ttttaaaagggg. For freespace, there are the following fields: ffffrrrreeeeeeeettttaaaagggg (0xffff), lllleeeennnnggggtttthhhh, and ttttaaaagggg. The ttttaaaagggg value is the byte offset in the block of the start of the entry it is contained in bbbblllleeeeaaaaffff: array of leaf entries containing hhhhaaaasssshhhhvvvvaaaallll and aaaaddddddddrrrreeeessssssss. The aaaaddddddddrrrreeeessssssss is a 64-bit word offset into the file bbbbttttaaaaiiiillll: tail structure containing the total ccccoooouuuunnnntttt of leaf entries and ssssttttaaaalllleeee count of unused leaf entries A data block contains the following fields: ddddhhhhddddrrrr: header containing mmmmaaaaggggiiiicccc number 0x58443244 ('XD2D') and an array bbbbeeeessssttttffffrrrreeeeeeee of the longest 3 free spaces in the block (ooooffffffffsssseeeetttt, lllleeeennnnggggtttthhhh) dddduuuu: array of union structures as for bbbbuuuu Leaf blocks have two possible forms. If the Btree consists of a single leaf then the freespace information is in the leaf block, otherwise it is in separate blocks and the root of the PPPPaaaaggggeeee 11111111 xxxxffffssss____ddddbbbb((((1111MMMM)))) xxxxffffssss____ddddbbbb((((1111MMMM)))) Btree is a node block. A leaf block contains the following fields: llllhhhhddddrrrr: header containing a bbbbllllkkkkiiiinnnnffffoooo structure iiiinnnnffffoooo (magic number 0xd2f1 for the single leaf case, 0xd2ff for the true Btree case), the total ccccoooouuuunnnntttt of leaf entries, and ssssttttaaaalllleeee count of unused leaf entries lllleeeennnnttttssss: leaf entries, as for bbbblllleeeeaaaaffff llllbbbbeeeessssttttssss: [single leaf only] array of values which represent the longest freespace in each data block in the directory llllttttaaaaiiiillll: [single leaf only] tail structure containing bbbbeeeessssttttccccoooouuuunnnntttt count of llllbbbbeeeessssttttssss A node block is identical to that for types aaaattttttttrrrr and ddddiiiirrrr. A freespace block contains the following fields: ffffhhhhddddrrrr: header containing mmmmaaaaggggiiiicccc number 0x58443246 ('XD2F'), ffffiiiirrrrssssttttddddbbbb first data block number covered by this freespace block, nnnnvvvvaaaalllliiiidddd number of valid entries, and nnnnuuuusssseeeedddd number of entries representing real data blocks ffffbbbbeeeessssttttssss: array of values as for llllbbbbeeeessssttttssss ddddqqqqbbbbllllkkkk The quota information is stored in files referred to by the superblock uuuuqqqquuuuoooottttiiiinnnnoooo and ppppqqqquuuuoooottttiiiinnnnoooo fields. Each filesystem block in a quota file contains a constant number of quota entries. The quota entry size is currently 136 bytes, so with a 4KB filesystem block size there are 30 quota entries per block. The ddddqqqquuuuooootttt command is used to locate these entries in the filesystem. The file entries are indexed by the user or project identifier to determine the block and offset. Each quota entry has the following fields: mmmmaaaaggggiiiicccc: magic number, 0x4451 ('DQ') vvvveeeerrrrssssiiiioooonnnn: version number, currently 1 ffffllllaaaaggggssss: flags, values include 0x01 for user quota, 0x02 for project quota iiiidddd: user or project identifier bbbbllllkkkk____hhhhaaaarrrrddddlllliiiimmmmiiiitttt: absolute limit on blocks in use bbbbllllkkkk____ssssooooffffttttlllliiiimmmmiiiitttt: preferred limit on blocks in use iiiinnnnoooo____hhhhaaaarrrrddddlllliiiimmmmiiiitttt: absolute limit on inodes in use iiiinnnnoooo____ssssooooffffttttlllliiiimmmmiiiitttt: preferred limit on inodes in use bbbbccccoooouuuunnnntttt: blocks actually in use iiiiccccoooouuuunnnntttt: inodes actually in use iiiittttiiiimmmmeeeerrrr: time when service will be refused if soft limit is violated for inodes bbbbttttiiiimmmmeeeerrrr: time when service will be refused if soft limit is violated for blocks iiiiwwwwaaaarrrrnnnnssss: number of warnings issued about inode limit violations bbbbwwwwaaaarrrrnnnnssss: number of warnings issued about block limit violations rrrrttttbbbb____hhhhaaaarrrrddddlllliiiimmmmiiiitttt: absolute limit on realtime blocks in use rrrrttttbbbb____ssssooooffffttttlllliiiimmmmiiiitttt: preferred limit on realtime blocks in use rrrrttttbbbbccccoooouuuunnnntttt: realtime blocks actually in use rrrrttttbbbbttttiiiimmmmeeeerrrr: time when service will be refused if soft limit is violated for realtime blocks PPPPaaaaggggeeee 11112222 xxxxffffssss____ddddbbbb((((1111MMMM)))) xxxxffffssss____ddddbbbb((((1111MMMM)))) rrrrttttbbbbwwwwaaaarrrrnnnnssss: number of warnings issued about realtime block limit violations iiiinnnnoooobbbbtttt There is one set of filesystem blocks forming the inode allocation Btree for each allocation group. The root block of this Btree is designated by the rrrrooooooootttt field in the corresponding AGI block. The blocks are linked to sibling left and right blocks at each level, as well as by pointers from parent to child blocks. Each block has the following fields: mmmmaaaaggggiiiicccc: INOBT block magic number, 0x49414254 ('IABT') lllleeeevvvveeeellll: level number of this block, 0 is a leaf nnnnuuuummmmrrrreeeeccccssss: number of data entries in the block lllleeeeffffttttssssiiiibbbb: left (logically lower) sibling block, 0 if none rrrriiiigggghhhhttttssssiiiibbbb: right (logically higher) sibling block, 0 if none rrrreeeeccccssss: [leaf blocks only] array of inode records. Each record contains ssssttttaaaarrrrttttiiiinnnnoooo allocation-group relative inode number, ffffrrrreeeeeeeeccccoooouuuunnnntttt count of free inodes in this chunk, and ffffrrrreeeeeeee bitmap, LSB corresponds to inode 0 kkkkeeeeyyyyssss: [nonleaf blocks only] array of key records. These are the first value of each block in the level below this one. Each record contains ssssttttaaaarrrrttttiiiinnnnoooo ppppttttrrrrssss: [nonleaf blocks only] array of child block pointers. Each pointer is a block number within the allocation group to the next level in the Btree iiiinnnnooooddddeeee Inodes are allocated in ``chunks'' of 64 inodes each. Usually a chunk is multiple filesystem blocks, although there are cases with large filesystem blocks where a chunk is less than one block. The inode Btree (see iiiinnnnoooobbbbtttt above) refers to the inode numbers per allocation group. The inode numbers directly reflect the location of the inode block on disk. Use the iiiinnnnooooddddeeee command to point _x_f_s__d_b to a specific inode. Each inode contains four regions: ccccoooorrrreeee, nnnneeeexxxxtttt____uuuunnnnlllliiiinnnnkkkkeeeedddd, uuuu, and aaaa. ccccoooorrrreeee contains the fixed information. nnnneeeexxxxtttt____uuuunnnnlllliiiinnnnkkkkeeeedddd is separated from the core due to journalling considerations, see type aaaaggggiiii field uuuunnnnlllliiiinnnnkkkkeeeedddd. uuuu is a union structure that is different in size and format depending on the type and representation of the file data (``data fork''). aaaa is an optional union structure to describe attribute data, that is different in size, format, and location depending on the presence and representation of attribute data, and the size of the uuuu data (``attribute fork''). _x_f_s__d_b automatically selects the proper union members based on information in the inode. The following are fields in the inode core: mmmmaaaaggggiiiicccc: inode magic number, 0x494e ('IN') mmmmooooddddeeee: mode and type of file, as described in cccchhhhmmmmoooodddd(2), mmmmkkkknnnnoooodddd(2), and ssssttttaaaatttt(2) vvvveeeerrrrssssiiiioooonnnn: inode version, 1 or 2 ffffoooorrrrmmmmaaaatttt: format of uuuu union data (0: dev_t, 1: local file - in- inode directory or symlink, 2: extent list, 3: Btree root, 4: unique id [unused]) nnnnlllliiiinnnnkkkkvvvv1111: number of links to the file in a version 1 inode PPPPaaaaggggeeee 11113333 xxxxffffssss____ddddbbbb((((1111MMMM)))) xxxxffffssss____ddddbbbb((((1111MMMM)))) nnnnlllliiiinnnnkkkkvvvv2222: number of links to the file in a version 2 inode pppprrrroooojjjjiiiidddd: owner's project id (version 2 inode only) uuuuiiiidddd: owner's user id ggggiiiidddd: owner's group id aaaattttiiiimmmmeeee: time last accessed (seconds and nanoseconds) mmmmttttiiiimmmmeeee: time last modified ccccttttiiiimmmmeeee: time created or inode last modified ssssiiiizzzzeeee: number of bytes in the file nnnnbbbblllloooocccckkkkssss: total number of blocks in the file including indirect and attribute eeeexxxxttttssssiiiizzzzeeee: basic/minimum extent size for the file, used only for realtime nnnneeeexxxxtttteeeennnnttttssss: number of extents in the data fork nnnnaaaaeeeexxxxtttteeeennnnttttssss: number of extents in the attribute fork ffffoooorrrrkkkkooooffffffff: attribute fork offset in the inode, in 64-bit words from the start of uuuu aaaaffffoooorrrrmmmmaaaatttt: format of aaaa data (1: local attribute data, 2: extent list, 3: Btree root) ddddmmmmeeeevvvvmmmmaaaasssskkkk: DMAPI event mask ddddmmmmssssttttaaaatttteeee: DMAPI state information nnnneeeewwwwrrrrttttbbbbmmmm: file is the realtime bitmap and is ``new'' format pppprrrreeeeaaaalllllllloooocccc: file has preallocated data space after EOF rrrreeeeaaaallllttttiiiimmmmeeee: file data is in the realtime subvolume ggggeeeennnn: inode generation number The following fields are in the uuuu data fork union: bbbbmmmmbbbbtttt: bmap Btree root. This looks like a bbbbmmmmaaaappppbbbbttttdddd block with redundant information removed bbbbmmmmxxxx: array of extent descriptors ddddeeeevvvv: dev_t for the block or character device ssssffffddddiiiirrrr: shortform (in-inode) version 1 directory. This consists of a hhhhddddrrrr containing the ppppaaaarrrreeeennnntttt inode number and a ccccoooouuuunnnntttt of active entries in the directory, followed by an array lllliiiisssstttt of hhhhddddrrrr.ccccoooouuuunnnntttt entries. Each such entry contains iiiinnnnuuuummmmbbbbeeeerrrr, nnnnaaaammmmeeeelllleeeennnn, and nnnnaaaammmmeeee string ssssffffddddiiiirrrr2222: shortform (in-inode) version 2 directory. This consists of a hhhhddddrrrr containing a ccccoooouuuunnnntttt of active entries in the directory, an iiii8888ccccoooouuuunnnntttt of entries with inumbers that don't fit in a 32-bit value, and the ppppaaaarrrreeeennnntttt inode number, followed by an array lllliiiisssstttt of hhhhddddrrrr.ccccoooouuuunnnntttt entries. Each such entry contains nnnnaaaammmmeeeelllleeeennnn, a saved ooooffffffffsssseeeetttt used when the directory is converted to a larger form, a nnnnaaaammmmeeee string, and the iiiinnnnuuuummmmbbbbeeeerrrr ssssyyyymmmmlllliiiinnnnkkkk: symbolic link string value The following fields are in the aaaa attribute fork union if it exists: bbbbmmmmbbbbtttt: bmap Btree root, as above bbbbmmmmxxxx: array of extent descriptors ssssffffaaaattttttttrrrr: shortform (in-inode) attribute values. This consists of a hhhhddddrrrr containing a ttttoooottttssssiiiizzzzeeee (total size in bytes) and a ccccoooouuuunnnntttt of active entries, followed by an array lllliiiisssstttt of hhhhddddrrrr.ccccoooouuuunnnntttt entries. Each such entry contains nnnnaaaammmmeeeelllleeeennnn, vvvvaaaalllluuuueeeelllleeeennnn, rrrrooooooootttt PPPPaaaaggggeeee 11114444 xxxxffffssss____ddddbbbb((((1111MMMM)))) xxxxffffssss____ddddbbbb((((1111MMMM)))) flag, nnnnaaaammmmeeee, and vvvvaaaalllluuuueeee lllloooogggg Log blocks contain the journal entries for XFS. It's not useful to examine these with _x_f_s__d_b, use _x_f_s__l_o_g_p_r_i_n_t(1M) instead. rrrrttttbbbbiiiittttmmmmaaaapppp If the filesystem has a realtime subvolume, then the rrrrbbbbmmmmiiiinnnnoooo field in the superblock refers to a file that contains the realtime bitmap. Each bit in the bitmap file controls the allocation of a single realtime extent (set == free). The bitmap is processed in 32-bit words, the LSB of a word is used for the first extent controlled by that bitmap word. The aaaattttiiiimmmmeeee field of the realtime bitmap inode contains a counter that is used to control where the next new realtime file will start. rrrrttttssssuuuummmmmmmmaaaarrrryyyy If the filesystem has a realtime subvolume, then the rrrrssssuuuummmmiiiinnnnoooo field in the superblock refers to a file that contains the realtime summary data. The summary file contains a two- dimensional array of 16-bit values. Each value counts the number of free extent runs (consecutive free realtime extents) of a given range of sizes that starts in a given bitmap block. The size ranges are binary buckets (low size in the bucket is a power of 2). There are as many size ranges as are necessary given the size of the realtime subvolume. The first dimension is the size range, the second dimension is the starting bitmap block number (adjacent entries are for the same size, adjacent bitmap blocks). ssssbbbb There is one sb (superblock) structure per allocation group. It is the first disk block in the allocation group. Only the first one (block 0 of the filesystem) is actually used; the other blocks are redundant information for _x_f_s__r_e_p_a_i_r(1M) to use if the first superblock is damaged. Fields defined: mmmmaaaaggggiiiiccccnnnnuuuummmm: superblock magic number, 0x58465342 ('XFSB') bbbblllloooocccckkkkssssiiiizzzzeeee: filesystem block size in bytes ddddbbbblllloooocccckkkkssss: number of filesystem blocks present in the data subvolume rrrrbbbblllloooocccckkkkssss: number of filesystem blocks present in the realtime subvolume rrrreeeexxxxtttteeeennnnttttssss: number of realtime extents that rrrrbbbblllloooocccckkkkssss contain uuuuuuuuiiiidddd: unique identifier of the filesystem llllooooggggssssttttaaaarrrrtttt: starting filesystem block number of the log (journal). If this value is 0 the log is ``external'' rrrroooooooottttiiiinnnnoooo: root inode number rrrrbbbbmmmmiiiinnnnoooo: realtime bitmap inode number rrrrssssuuuummmmiiiinnnnoooo: realtime summary data inode number rrrreeeexxxxttttssssiiiizzzzeeee: realtime extent size in filesystem blocks aaaaggggbbbblllloooocccckkkkssss: size of an allocation group in filesystem blocks aaaaggggccccoooouuuunnnntttt: number of allocation groups rrrrbbbbmmmmbbbblllloooocccckkkkssss: number of realtime bitmap blocks llllooooggggbbbblllloooocccckkkkssss: number of log blocks (filesystem blocks) vvvveeeerrrrssssiiiioooonnnnnnnnuuuummmm: filesystem version information. This value is PPPPaaaaggggeeee 11115555 xxxxffffssss____ddddbbbb((((1111MMMM)))) xxxxffffssss____ddddbbbb((((1111MMMM)))) currently 1, 2, 3, or 4 in the low 4 bits. If the low bits are 4 then the other bits have additional meanings. 1 is the original value. 2 means that attributes were used. 3 means that version 2 inodes (large link counts) were used. 4 is the bitmask version of the version number. In this case, the other bits are used as flags (0x0010: attributes were used, 0x0020: version 2 inodes were used, 0x0040: quotas were used, 0x0080: inode cluster alignment is in force, 0x0100: data stripe alignment is in force, 0x0200: the sssshhhhaaaarrrreeeedddd____vvvvnnnn field is used, 0x1000: unwritten extent tracking is on, 0x2000: version 2 directories are in use) sssseeeeccccttttssssiiiizzzzeeee: sector size in bytes, currently always 512. This is the size of the superblock and the other header blocks iiiinnnnooooddddeeeessssiiiizzzzeeee: inode size in bytes iiiinnnnooooppppbbbblllloooocccckkkk: number of inodes per filesystem block ffffnnnnaaaammmmeeee: obsolete, filesystem name ffffppppaaaacccckkkk: obsolete, filesystem pack name bbbblllloooocccckkkklllloooogggg: log2 of bbbblllloooocccckkkkssssiiiizzzzeeee sssseeeeccccttttlllloooogggg: log2 of sssseeeeccccttttssssiiiizzzzeeee iiiinnnnooooddddeeeelllloooogggg: log2 of iiiinnnnooooddddeeeessssiiiizzzzeeee iiiinnnnooooppppbbbblllloooogggg: log2 of iiiinnnnooooppppbbbblllloooocccckkkk aaaaggggbbbbllllkkkklllloooogggg: log2 of aaaaggggbbbblllloooocccckkkkssss (rounded up) rrrreeeexxxxttttsssslllloooogggg: log2 of rrrreeeexxxxtttteeeennnnttttssss iiiinnnnpppprrrrooooggggrrrreeeessssssss: _m_k_f_s__x_f_s(1M) aborted before completing this filesystem iiiimmmmaaaaxxxx____ppppcccctttt: maximum percentage of filesystem space used for inode blocks iiiiccccoooouuuunnnntttt: number of allocated inodes iiiiffffrrrreeeeeeee: number of allocated inodes that are not in use ffffddddbbbblllloooocccckkkkssss: number of free data blocks ffffrrrreeeexxxxtttteeeennnnttttssss: number of free realtime extents uuuuqqqquuuuoooottttiiiinnnnoooo: user quota inode number ppppqqqquuuuoooottttiiiinnnnoooo: project quota inode number; this is currently unused qqqqffffllllaaaaggggssss: quota status flags (0x01: user quota accounting is on, 0x02: user quota limits are enforced, 0x04: quotacheck has been run on user quotas, 0x08: project quota accounting is on, 0x10: project quota limits are enforced, 0x20: quotacheck has been run on project quotas) ffffllllaaaaggggssss: random flags. 0x01: only read-only mounts are allowed sssshhhhaaaarrrreeeedddd____vvvvnnnn: shared version number (shared readonly filesystems) iiiinnnnooooaaaalllliiiiggggnnnnmmmmtttt: inode chunk alignment in filesystem blocks uuuunnnniiiitttt: stripe or RAID unit wwwwiiiiddddtttthhhh: stripe or RAID width ddddiiiirrrrbbbbllllkkkklllloooogggg: log2 of directory block size (filesystem blocks) ssssyyyymmmmlllliiiinnnnkkkk Symbolic link blocks are used only when the symbolic link value does not fit inside the inode. The block content is just the string value. Bytes past the logical end of the symbolic link value have arbitrary values. PPPPaaaaggggeeee 11116666 xxxxffffssss____ddddbbbb((((1111MMMM)))) xxxxffffssss____ddddbbbb((((1111MMMM)))) DDDDIIIIAAAAGGGGNNNNOOOOSSSSTTTTIIIICCCCSSSS Many messages can come from the cccchhhheeeecccckkkk (bbbblllloooocccckkkkggggeeeetttt) command; these are documented in _x_f_s__c_h_e_c_k(1M). SSSSEEEEEEEE AAAALLLLSSSSOOOO mkfs_xfs(1M), xfs_check(1M), xfs_copy(1M), xfs_logprint(1M), xfs_ncheck(1M), xfs_repair(1M), chmod(2), mknod(2), stat(2), xfs(4). PPPPaaaaggggeeee 11117777 
